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Status of this Memo 
This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
Abstract 
This document describes how to use CBC-mode cipher algorithms with 
the IPSec ESP (Encapsulating Security Payload) Protocol. It not only 
clearly states how to use certain cipher algorithms, but also how to 


use all CBC-mode cipher algorithms. 
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1. Introduction 


The Encapsulating Security Payload (ESP) [Kent98] provides 
confidentiality for IP datagrams by encrypting the payload data to be 
protected. This specification describes the ESP use of CBC-mode 
cipher algorithms. 


While this document does not describe the use of the default cipher 
algorithm DES, the reader should be familiar with that document. 
[Madson98] 


It is assumed that the reader is familiar with the terms and concepts 
described in the "Security Architecture for the Internet Protocol" 
[Atkinson95], "IP Security Document Roadmap" [Thayer97], and "IP 
Encapsulating Security Payload (ESP)" [Kent98] documents. 


Furthermore, this document is a companion to [Kent98] and MUST be 
read in its context. 


1.1 Specification of Requirements 
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 


and "MAY" that appear in this document are to be interpreted as 
described in [Bradner97]. 


1.2 Intellectual Property Rights Statement 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementers or users of this specification can 
be obtained from the IETF Secretariat. 


2. Cipher Algorithms 
All symmetric block cipher algorithms share common characteristics 


and variables. These include mode, key size, weak keys, block size, 
and rounds. All of which will be explained below. 
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While this document illustrates certain cipher algorithms such as 
Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV], 
and RC5 [Baldwin96], any other block cipher algorithm may be used 
with ESP if all of the variables described within this document are 
clearly defined. 


2.1 Mode 


All symmetric block cipher algorithms described or insinuated within 
this document use Cipher Block Chaining (CBC) mode. This mode 
requires an Initialization Vector (IV) that is the same size as the 
block size. Use of a randomly generated IV prevents generation of 
identical ciphertext from packets which have identical data that 
spans the first block of the cipher algorithm’s blocksize. 


The IV is XOR’d with the first plaintext block, before it is 
encrypted. Then for successive blocks, the previous ciphertext block 
is XOR’d with the current plaintext, before it is encrypted. 


More information on CBC mode can be obtained in [Schneier95]. 
2.2 Key Size 


Some cipher algorithms allow for variable sized keys, while others 
only allow a specific key size. The length of the key correlates 
with the strength of that algorithm, thus larger keys are always 
harder to break than shorter ones. 


This document stipulates that all key sizes MUST be a multiple of 8 
bits. 


This document does specify the default key size for each cipher 
algorithm. This size was chosen by consulting experts on the 
algorithm and by balancing strength of the algorithm with 
performance. 
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+ + + + + 
| Algorithm | Key Sizes (bits) | Popular Sizes | Default | 
+ + + + + 
| CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | 
4+-------------- +------------------ +----------------- Homo + 
| ROS | 40 to 2040 | 40, 128, 160 | 128 | 
+-------------- $ oo +----------------- +---------- + 
| IDEA | 128 | 128 | 128 | 
+-------------- $ oo 4+----------------- +---------- + 
| Blowfish | 40 to 448 | 128 | 128 | 
+-------------- +------------------ +----------------- +---------- + 
| 3DES [2] | 192 | 192 | 192 | 
+-------------- Ho oo 4+----------------- +---------- + 
Notes: 


[1] With CAST-128, keys less than 128 bits MUST be padded with zeros 
in the rightmost, or least significant, positions out to 128 bits 
since the CAST-128 key schedule assumes an input key of 128 bits. 
Thus if you had a key with a size of 80 bits ’3B5D831CFE’, it would 
be padded to produce a key with a size of 128 bits 

/ 3B5D831CFE000000/. 


[2] The first 3DES key is taken from the first 64 bits, the second 
from the next 64 bits, and the third from the last 64 bits. 
Implementations MUST take into consideration the parity bits when 
initially accepting a new set of keys. Each of the three keys is 
really 56 bits in length with the extra 8 bits used for parity. 


The reader should note that the minimum key size for all of the above 
cipher algorithms is 40 bits, and that the authors strongly advise 
that implementations do NOT use key sizes smaller than 40 bits. 


2.3 Weak Keys 
Weak key checks SHOULD be performed. If such a key is found, the key 
SHOULD be rejected and a new SA requested. Some cipher algorithms 
have weak keys or keys that MUST not be used due to their weak 
nature. 
New weak keys might be discovered, so this document does not in any 
way contain all possible weak keys for these ciphers. Please check 
with other sources of cryptography such as [MOV] and [Schneier] for 
further weak keys. 


CAST-128: 


No known weak keys. 
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RC5: 


No known weak keys when used with 16 rounds. 


IDEA: 


IDEA has been found to have weak keys. Please check with [MOV] and 
[Schneier] for more information. 


Blowfish: 


Weak keys for Blowfish have been discovered. Weak keys are keys that 
produce the identical entries in a given S-box. Unfortunately, there 
is no way to test for weak keys before the S- box values are 
generated. However, the chances of randomly generating such a key 
are small. 


3DES: 


DES has 64 known weak keys, including so-called semi-weak keys and 
possibly-weak keys [Schneier95, pp 280-282]. The likelihood of 
picking one at random is negligible. 


For DES-EDE3, there is no known need to reject weak or 
complementation keys. Any weakness is obviated by the use of 
multiple keys. 


However, if the first two or last two independent 64-bit keys are 
equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the 
same as DES. Implementers MUST reject keys that exhibit this 
property. 


2.4 Block Size and Padding 


All of the algorithms described in this document use a block size of 
eight octets (64 bits). 


Padding is used to align the payload type and pad length octets as 


specified in [Kent98]. Padding must be sufficient to align the data 
to be encrypted to an eight octet (64 bit) boundary. 
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2.5 Rounds 


This variable determines how many times a block is encrypted. While 
this variable MAY be negotiated, a default value MUST always exist 
when it is not negotiated. 


+ + + + 
| Algorithm | Negotiable | Default Rounds 

+ + + + 
| CAST-128 | No | key<=80 bits, 12 | 
| | | key>80 bits, 16 | 
4+-------------------- 4+------------ +---------------------- + 
| RC5 | No | 16 | 
4+-------------------- 4+------------ $ + 
| IDEA | No | 8 | 
4+-------------------- 4+------------ $ + 
| Blowfish | No | 16 

$ ooo Ho 4---------------------- + 
| 3DES | No | 48 (16x3) | 
4+-------------------- 4+------------ 4---------------------- + 


2.6 Backgrounds 
CAST-128: 


The CAST design procedure was originally developed by Carlisle Adams 
and Stafford Tavares at Queen’s University, Kingston, Ontario, 
Canada. Subsequent enhancements have been made over the years by 
Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128 
is the result of applying the CAST Design Procedure as outlined in 
[Adams97] . 


RC5: 


The RC5 encryption algorithm was developed by Ron Rivest for RSA Data 
Security Inc. in order to address the need for a high- performance 
software and hardware ciphering alternative to DES. It is patented 
(pat.no. 5,724,428). A description of RC5 may be found in [MOV] and 
[Schneier]. 


IDEA: 
Xuejia Lai and James Massey developed the IDEA (International Data 


Encryption Algorithm) algorithm. The algorithm is described in 
detail in [Lai], [Schneier] and [MOV]. 
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The IDEA algorithm is patented in Europe and in the United States 
with patent application pending in Japan. Licenses are required for 
commercial uses of IDEA. 


For patent and licensing information, contact: 


Ascom Systec AG, Dept. CMVV 

Gewerbepark, CH-5506 

Magenwil, Switzerland 

Phone: +41 64 56 59 83 

Fax: +41 64 56 59 90 

idea@ascom.ch 
http://www.ascom.ch/Web/systec/policy/normal/exhibit1l.html 


Blowfish: 


Bruce Schneier of Counterpane Systems developed the Blowfish block 
cipher algorithm. The algorithm is described in detail in 
[Schneier93], [Schneier95] and [Schneier]. 


3DES: 


This DES variant, colloquially known as "Triple DES" or as DES-EDE3, 
processes each block three times, each time with a different key. 
This technique of using more than one DES operation was proposed in 
[Tuchman79]. 


P1 P2 Pi 
| | | 
IV->-> (X) +>->->-> (X) +>->->-> (X) 
v A v A v 
+==--- + ^ +----- + ^ +----- + 
kl=>| E | %kl>] E | * ki->| E | 
+----- + ^ +----- + +----- + 
| ‘ | | 
v e v e v 
+=-=--- + ^ +----- + ^ +----- + 
k2->| D | ^ k2->| D | * k2->| D | 
+----- + ^ +----- + ^ +----- + 
| ^ | i | 
v ~ v > v 
+=-=--- + ^ +----- + ^ +----- + 
k3->| E | ^ k3->| E | ^ k3->| E | 
+----- + ^ +----- + ^ +----- + 
| ^ | 5 | 
+>->->+ +>->->+ +>->-> 
| | | 
cl C2 Ci 
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The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC 
algorithm [FIPS-46]. The "outer" chaining technique is used. 


In DES-EDE3-CBC, an Initialization Vector (IV) is XOR’d with the 
first 64-bit (8 byte) plaintext block (P1). The keyed DES function 
is iterated three times, an encryption (Ek1) followed by a decryption 
(Dk2) followed by an encryption (Ek3), and generates the ciphertext 
(C1) for the block. Each iteration uses an independent key: kl, k2 
and k3. 


For successive blocks, the previous ciphertext block is XOR’d with 
the current plaintext (Pi). The keyed DES-EDE3 encryption function 
generates the ciphertext (Ci) for that block. 


To decrypt, the order of the functions is reversed: decrypt with k3, 
encrypt with k2, decrypt with kl, and XOR the previous ciphertext 
block. 


Note that when all three keys (k1, k2 and k3) are the same, DES- 
EDE3-CBC is equivalent to DES-CBC. This property allows the DES-EDE3 
hardware implementations to operate in DES mode without modification. 


For more explanation and implementation information for Triple DES, 
see [Schneier95]. 


2.7 Performance 
For a comparison table of the estimated speed of any of these and 
other cipher algorithms, please see [Schneier97] or for an up-to-date 
performance comparison, please see [Bosseleaers]. 

3. ESP Payload 
The ESP payload is made up of the IV followed by raw cipher-text. 


Thus the payload field, as defined in [Kent98], is broken down 
according to the following diagram: 


4+--------------- +--------------- +--------------- +--------------- + 
+ Initialization Vector (8 octets) + 
+--------------- +--------------- 4+--------------- +--------------- + 


Mi Encrypted Payload (variable length) 


LASA iS A zo Sao dol iS Arde 
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The IV field MUST be same size as the block size of the cipher 
algorithm being used. The IV MUST be chosen at random. Common 
practice is to use random data for the first IV and the last block of 
encrypted data from an encryption process as the IV for the next 
encryption process. 


Including the IV in each datagram ensures that decryption of each 
received datagram can be performed, even when some datagrams are 
dropped, or datagrams are re-ordered in transit. 


To avoid ECB encryption of very similar plaintext blocks in different 
packets, implementations MUST NOT use a counter or other low-Hamming 
distance source for IVs. 


3.1 ESP Environmental Considerations 


Currently, there are no known issues regarding interactions between 
these algorithms and other aspects of ESP, such as use of certain 
authentication schemes. 


3.2 Keying Material 


The minimum number of bits sent from the key exchange protocol to 
this ESP algorithm must be greater or equal to the key size. 


The cipher’s encryption and decryption key is taken from the first 
<x> bits of the keying material, where <x> represents the required 
key size. 


4. Security Considerations 


Implementations are encouraged to use the largest key sizes they can 
when taking into account performance considerations for their 
particular hardware and software configuration. Note that encryption 
necessarily impacts both sides of a secure channel, so such 
consideration must take into account not only the client side, but 
the server as well. 


For information on the case for using random values please see 
[Be1197]. 


For further security considerations, the reader is encouraged to read 
the documents that describe the actual cipher algorithms. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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